1. Field of the Invention
The present inventions relates to software executable libraries/sub-libraries of functions and more particularly to the processing of a library which comprises a plurality of sub-libraries.
2. Background to the Invention
A well known and widely used method of providing software functions to a software application installed on a computer system is to provide an appropriate library which contains the executable software functions. The software application links to the library in order to discover/resolve the locations within the library of the various executable routines/methods which it provides to perform the software functions. The application may then call the resolved/discovered routines/methods.
Libraries may be either statically or dynamically linked to an application executable file. In static linking the application executable file includes a linked instance of the library, whereas in dynamic linking the application executable file links to a separate instance of the library at load time. Comparing the two methods, static linking has an advantage in that the application executable file will load relatively faster because the library does not need to be linked at load time, but has disadvantages in that it increases the size of the application executable file and further the library instance included in the application executable file is not sharable by other applications. Dynamic linking has advantages in that the application executable file is relatively smaller and the instance of the library which is linked can be shared by other applications, but it has a disadvantage in that it slows down application load because the library must be linked at application load time.
A library which is dynamically linkable may be referred to as a dynamic link library or dll and there are different ways in which such a library can be linked. For example a standard way of dynamically linking a dll is where the application executable file includes calls to specific functions/routines of a named dll library, which it wishes to call. The calls are specified such that they must be resolved at either load time or at some point during run time by loading the named dll. As a result the named dll must be available to be loaded when required by the application executable or the application will fail. Further, for example, the application executable is limited to using the named dll for the specific functions/routines.
For example, another way of dynamically linking is through provision of a plug-in dll. A plug-in dll provides a standard method which may be called in order to initialize the plug-in dll and obtain/discover details of the methods/routines which the plug-in dll provides. Accordingly, for plug-in dlls, for example, the application (or more typically a plug-in manger which is used by the application) looks for the presence of plug-in dlls in a specified location of the computer system on which the application is loaded. If such a dll is found the application/plug-in manager calls the standard method of the dll to obtain details of the routines/methods which it provides. These routines/methods are then made available for calling by the application executable. An advantage of using plug-in dlls is the plug-in based architecture allows for tailoring of the functionality of the application via the addition or removal of plug-in dlls. For example, the addition or removal of a plug-in dll can happen after the product which provides the plug-in dll has been installed. The characteristic of a plug-in dll which makes this possible is the standard method which each plug-in dll provides and which may be called to discover the other methods/routines which the plug-in dll provides.
Accordingly providers of software products which provide software services to applications may provide such products in the form of one or more dlls. However, the size of a dll is variable and accordingly a decision must be made as to how many dlls to use in order provide a product. For example, an advantage of providing a product as many small dlls, when compared to a single large dll, is that it makes it easier to provide fixes/and or updates to products because only the affected dll need be replaced. Conversely, for example, disadvantages are that each dll incurs the overhead associated with being loaded at runtime and further each dll incurs a storage overhead making, for example, a product supplied as many dlls larger than the same product as a single dll. For example, for plug-in dlls each plug-in dll must contain a standard method which can be used to initialize it and obtain details of the methods/routines which the plug-in dll provides, and a proportion of the code in the method is common amongst all plug-ins. As a result the common code is reproduced once for each plug-in dll and this adds to overall the size of a product.
Accordingly there becomes a trade-off between maintainability and storage space required for a product and often an optimal solution is not possible. Further because a change to/from a single dll from/to a plurality of dlls requires modification of the underlying code, it requires some effort by the provider of a product to either increase or decrease the dlls used in order to provide that product.